Subject: HPR SIG minutes

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Thu, 25 May 95 11:25:27 EDT

____________________________________________________________________

                 APPN Implementers' Workshop
                      San Jose, CA, USA
                         May 4, 1995
____________________________________________________________________

                           Minutes
                           HPR SIG

o  We reviewed AIW 6 network management issues, functional changes,
   and editorial changes.  These were agreed upon, with the following
   exceptions:
   - SNMP Traps should be defined corresponding to HPR Alerts.
   - Documentation of erroneous Route Setup backout by destination node
     still needs to be added.

o  A long and tortuous discussion of open issues took place.  The two
   main issues, raised by Jim Cobban of Nortel and documented in prior
   e-mail on this forum, were:
     (1) Formats for HPR over LAN 802.2 pose several problems for
         DLC-layer gateways.
     (2) Modifications are suggested for HPR formats over Frame Relay.
   In summary, the SIG decided not to change HPR for problem 1, but to
   consider adding a tower after CP for problem 2.  Details of both
   discussions are below.

o  SIG consensus was that HPR met requirements for CP.  CP was ratified
   by the AIW plenary on May 4, 1995.

o  Future work.  Ray Bird will continue maintaining the document for a
   while and the SIG will stay open at least thru AIW 8.  Formats for
   HPR over ATM can be done at the Reference SIG or ATM BOF(SIG).
   Members are interested in:
     - An API to access RTP directly.  Is there a patent issue?
     - Changing the LLC to LLC1
     - Using RTP for unreliable delivery, e.g. for video
     - Network management will be done in the APPN/HPR MIB group,
       e.g., tracing lost ANR packets...

Someday each of us can look back and say, "I was there, I helped make it
happen."  Thank you, everybody, for supporting the work of the HPR SIG.

Marcia Peters, chair

:end summary
_______________________________________________________________________
:begin details

(I'll apologize in advance because I'm sure these minutes don't capture
all the nuances adequately.)

+-------------+
|  Problem 1  |
+-------------+

IBM:       Proposes the use of 802.2 type 1 (LLC1) with SAP C8 (or
           other), with LLC2 being optional.
Nortel:    Counterproposes that LLC2 be base and LLC1 optional for the
           following reasons:  Supporting UI requires modifying SNA
           devices.  This has less overhead, but the overhead is all in
           the adapter.  Since adapters are faster than the host, even
           when handling LLC2, keep this work in the adapter.
InSession: The issue is not adapter speed, but turnaround time for acks.

Members' arguments against Nortel's position included the following:

Cisco:     Arch should not be changed to support slow implementations.
           Adapters already support LLC1 for NetBIOS.  Putting a
           windowing protocol <LLC2> under ARB will screw it up.
Nortel:    Our implementation bridges NetBIOS, doesn't support UI.
InSession: The 802.2 spec says that LLC2 necessarily includes LLC1.
Nortel:    But not on a SAP I haven't heard of.
InSession: The SAP and UI issues are separate.  Nortel should fix their
           UI problem.
Cisco:     The SAP issue is important.
Nortel:    We can modify the HPR CV61 on XID3s flowing thru our box.
Chair:     Implementations can be configured to support the Nortel
           G/W.  Should we make this configuration base?
IBM 6611:  We disagree.  We depend on SAPs <04 for XID and C8/other for
           HPR NLP> being different.  We don't want to force them to be
           the same.  After looking at SNAP headers, C8 was a compromise
           among IBM products.
Cisco:     If everyone supports configurable SAPs, Nortel will be happy.
IBM 6611:  6611 SAPs can be configured, but they have to be different.
IBM arch:  The IBM products consider the ability to use the same SAP
           a tower.
Nortel:    I can muck with CV61 to force the link to use LLC2.
Chair:     Is that acceptable?
Nortel:    Yes, but it only will work if the HPR products actually
           support running over LLC2 <i.e. LLC2 must be base function>.
           Pre-standard implementations have to accept the risk <that
           the standard may change>.
IBM Arch:  You can just remove CV61 and the link runs as APPN ISR <a
           compromise not requiring any changes to IBM's HPR products.>
Nortel:    OK, I could flip the CV61 to ERP, & that will work for NCP
           and CM/2 <assuming they support ERP links in HPR>, but for
           6611 I'd have to force ISR by removing CV61.  OK, if I see
           non-ERP only <sent by either side>, then I'll remove CV61.
           At least that gets connectivity, and I still get HPR in some
           cases.
All:       That's a compromise we can live with.

AGREEMENT:  We agreed to make no changes in this area, i.e.:
            (1) not to make the ERP tower a base function
            (2) not to make LLC2 support a base function
            (3) not to make the ability to run HPR on a single SAP
                base function
            (4) not to make SAP configurability base function.

+-------------+
|  Problem 2  |
+-------------+

A documentation change is needed creating a new tower.  If XID
explicitly requests a SAP pair other than C8-C8 <for NLPs>, then use
the new format that includes SAPs.  This is a minor addition.

IBM arch:   This was acceptable to CM/2 and probably 6611.  I'll
            double-check with IBM products.
Nortel:     There's no urgency to get this in before CP.
Somebody:   Another option is to use BAN; it will insulate <a G/W> from
            endpoint changes better.
IBM arch:   That's independent of HPR; go ahead and do it.
Chair:      That should be documented somewhere, but not in HPR.
AIW Chair:  Let's do that through the Reference SIG.

(( No, I didn't use a tape recorder! Thanks to Ralph Case for taking
really great notes!! ))   ;-)

                           * * * * *